home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / 91nov / avtbof-minutes-91nov.txt < prev    next >
Text File  |  1993-02-17  |  6KB  |  139 lines
  1.            Audio/Video Transport WG Meeting Report
  2.              21-Nov-91, Santa Fe
  3.  
  4. 1. Scope of this working group
  5.  
  6. In the Teleconferencing BOF two days earlier, several areas of
  7. interest were identified.  One area was deemed ready for a working
  8. group: the Audio/Video Transport WG was formed to specify protocols
  9. for real-time transmission of audio and video over UDP and IP
  10. multicast, and this kickoff meeting was scheduled.
  11.  
  12. The purpose of this working group is to foster interoperation among
  13. several packet audio/video experiments already underway using UDP.
  14. Many hosts on the Internet have the capability now to do 64Kb/s PCM
  15. audio, and many could inexpensively add frame-grabbers and simple
  16. software compression for low-frame-rate video.  We want to enable
  17. desktop teleconferencing among these hosts.  Therefore, the focus of
  18. the WG is short-term: our goal is to have the protocols defined and
  19. experimental implementations running by the July 1992 IETF meeting.
  20.  
  21. UDP transmission of audio/video is only sufficient for small-scale
  22. experiments over fast portions of the Internet.  Scaling up will
  23. require network resource management and more sophisticated connection
  24. management; these are subjects of current research that we will defer
  25. to later working groups.
  26.  
  27.  
  28. 2. Who might contribute
  29.  
  30. Our first step will be to solicit contributions of potential protocols
  31. from those projects that are already experimenting with packet audio
  32. and video.  From these contributions we will distill the appropriate
  33. protocol features.  Many projects are working on "multimedia", but
  34. that is a wide topic.  We are particularly interested in those who are
  35. working on packet transmission of real-time media.  Some 25-30
  36. projects were suggested as candidates by meeting participants.
  37.  
  38.  
  39. 3. Brief descriptions of some existing protocols
  40.  
  41. Of the projects represented by the participants, three have audio and/or
  42. video protocols already in use.
  43.  
  44.   - Paul Milazzo from BBN described the protocol used in the Desktop
  45.     Video Conference program.  DVC uses the low-cost VideoPix
  46.     frame-grabber card for SPARCstations plus software compression to
  47.     generate video at about 5 frames per second.  The DVC protocol
  48.     communicates sequences of video subimage blocks over either TCP or
  49.     UDP.
  50.  
  51.   - Hans Eriksson from SICS described the PicturephoneTalk program.
  52.     It uses TCP connections to carry uncompressed images from the
  53.     VideoPix card and 64Kb/s PCM audio from the built-in audio device.
  54.     The protocols include timestamps to allow synchronization of the
  55.     streams at the receiver.
  56.  
  57.   - Steve Casner from ISI described the Network Voice Protocol (NVP)
  58.     and Packet Video Protocol (PVP) that have been in use for several
  59.     years in the multimedia conferencing system operating on the
  60.     TWBnet, and more recently on DARTnet.  The data packet formats
  61.     that are part of these protocols are fairly simple.  They have
  62.     been used over both ST (Stream Protocol) and UDP.
  63.  
  64. Short descriptions will be prepared for each of these three protocols
  65. to serve as models in the solicitation for contributions from other
  66. projects.
  67.  
  68.  
  69. 4. Issues to be addressed
  70.  
  71. A number of protocol issues have already been identified from
  72. differences among the protocols known to the participants.  In this
  73. first session, we did not get to any serious discussion of these
  74. issues, but some are included here to start your thinking:
  75.  
  76.   - Are there functions needed for both audio and video that should be
  77.     extracted into a lightweight real-time transport protocol layer?
  78.     One candidate might be timestamp information for synchronization.
  79.  
  80.   - Should timestamps be based on the media sample clock or on real
  81.     time? 
  82.  
  83.   - Should sequence numbers count packets or smaller units such as
  84.     samples? 
  85.  
  86.   - What should be the expected lifetime of the protocols produced by
  87.     this working group?  Are they only to be used in the short term
  88.     with UDP, or perhaps later directly over a real-time internet
  89.     protocol? 
  90.  
  91.   - NVP and PVP include checksums over the header because they run
  92.     over ST which provides no checksum.  Should such a feature be
  93.     included in our new protocols in anticipation of their use over
  94.     protocols other than UDP?
  95.  
  96.   - The CCITT recommendation G.764 Packetized Voice Protocol includes
  97.     a field that records the cumulative variable queueing delays
  98.     experienced by a packet in traversing the network.  This may be
  99.     useful for deadline-scheduling of packet forwarding, but is it
  100.     practical to expect Internet routers to update this field?
  101.  
  102.   - The Xerox PARC Phoenixphone protocol includes an "energy" value
  103.     for each data packet; should this be included?
  104.  
  105.   - Should we provide a mechanism for communicating control functions
  106.     within data packets?
  107.  
  108. It is expected that additional issues will be identified when
  109. additional protocols are contributed.  Further discussion will occur
  110. in subsequent teleconference meetings and by e-mail.
  111.  
  112.  
  113. 6. Next meeting
  114.  
  115. We've set an ambitious goal to hold the next meeting of the working
  116. group by packet audio teleconference in mid-January.  The initial plan
  117. is to use the UDP packet audio software for SPARCstations now used on
  118. DARTnet, and to employ DARTnet as an IP Multicast backbone.  From
  119. DARTnet end nodes we can use IP Multicast Tunneling to other WG member
  120. sites.  We need to begin immediately to test whether network
  121. performance on these potential tunnel paths is sufficient.
  122.  
  123. It is unlikely that all WG members will be able to participate by
  124. packet audio.  It will be possible to set up a telephone conference
  125. call for some sites and to patch that into the packet audio
  126. conference.  We may also face the problem of too much timezone spread
  127. among the interested parties (Oz to Europe) to be able to include
  128. everyone.
  129.  
  130. The topic for the teleconference meeting will be a discussion of the
  131. protocol issues listed above plus others that arise as we learn more
  132. about additional existing protocols that should be considered in the
  133. design process.  The solicitation for descriptions of these potential
  134. contributing protocols will be sent to the WG mailing list
  135. (rem-conf@es.net) and individually to contacts for each of the 25-30
  136. projects already identified, in case they are not on the list.
  137. Anyone wishing to make a contribution is invited to send a short note
  138. to the chair (casner@isi.edu) requesting the solicitation.
  139.